A database is an organized collection of data. In a distributed database system, a database can be spread across multiple database nodes, which can be located at different physical locations and operated by different server computers. For example, a database table can be split, or partitioned, such that different records of the table are stored at different database nodes. Values of a database can be inserted, deleted, edited or otherwise manipulated.
In a database system, a transaction is a logical operation or set of operations to manipulate data in a database (e.g., by insertion, deletion, editing, etc.). A transaction is typically processed as a unit of work involving the data. To process transactions reliably, a database system can follow a set of principles known by the acronym ACID, which stands for Atomicity, Consistency, Isolation and Durability. According to the principle of atomicity, if one part of a transaction fails, the entire transaction fails, and the state of the database is not changed. Outside the database system, a committed transaction is indivisible, and an aborted transaction does not happen. According to the principle of consistency, a transaction changes a database from one valid state to another valid state, following any rules, constraints, etc. that apply for the database. According to the principle of isolation, executing multiple transactions serially results in the same state as executing the transactions concurrently. According to the principle of durability, a committed transaction is stored persistently in the database.
A transaction log records changes in the database system. Entries of a transaction log can represent data changes or events (such as transactions being committed or rolled back). When a server “commits” a transaction, the server stores the results of the transaction in a persistent way in the database. That is, the results of the transaction are “persisted,” or stored to “disk,” which represents a hard drive, flash memory or some other non-volatile storage or memory. Typically, to commit transactions, the server persists transaction log entries for the transactions. Actual changed data might or might not be persisted at the same time, but in any case the state of the database can be restored using the persisted transaction log entries.
In some scenarios, previous approaches to committing transactions in a database system are inefficient in terms of computational efficiency and/or network bandwidth utilization. In particular, waiting for completion of disk input/output (“I/O”) operations and network I/O operations can result in wasted processing resources in many situations.